AFO 447 – Physical guest loans – update
447.1 Introduction
The “Physical Guest Loans”functionality allows borrowers of library A to enroll and loan items in library B, although library B is not on the same network. Library B may even use a totally different library system.
To realize this functionality the two library systems (A and B in our example) will have to exchange information. The exchange mechanisms are based on webservices (via the SOAP protocol).
Functionality and workflow overview
The example uses the following elements:
· Borrower X is a member at Library A
· Library A is the borrower's “home library”
· Library B is the borrower's “guest library”
The (much abbreviated) workflow is as follows:
1. Borrower X is a valid member at Library A.
2. Borrower X enters Library B and wants to enroll. He shows his library card and indicates that he is a borrower at Library A.
3. The borrower is enrolled at Library B via a specific workflow. During this workflow the system will retrieve (via a webservice) data from the borrower record as defined at Library A; the system will also check if the borrower has a valid membership, whether or not his record is blocked and whether or not he is allowed to participate in physical guest circulation. The borrower is enrolled at Library B.
4. The borrower can now loan items at Library B. These loans will, at Library B, behave as “normal” loans. However, the loans are also sent to Library A (via a webservice) and stored in Library A's database (for a number of technical reasons). Library A will also display the loans made at Library B in the following cases:
· in the client interface: the overview of items on loan will contain a specific section [alternatively, the system may give access via a separate option] [this will be decided at implementation time]
· in the Web OPAC user activities: the overview of items on loan will contain a specific section, clearly indicating that the items were loaned at which guest library
· on cumulative loan slips:
Please note
The guest library does not display the items on loan in other guest libraries or in the home library. However, the system may mention the fact that there may be loans at other libraries.
5. If applicable, all further processing (overdues, invoicing, etc.) is handled by Library B.
6. The borrower can return the item at Library A (home) or Library B (guest). The system will make sure that the return is processed correctly, wherever the item may have been returned. Returns at other libraries (Library C) are not handled; if they are allowed a pragmatic solution will have to be created outside of the ILS.
7. During the lifecycle of the loan, guest and home library will exchange information about both borrower and any items that were loan at the guest library.
Architecture and requirements
·
Physical guest loan uses a decentralized concept, i.e. there is no central server on which all “guest loans” are registered. All guest loans are stored on both guest and home library. No middleware is used to store the transactions.
·
The home library always has a full overview of all loans (at all guest libraries).
·
The guest libraries only maintain an overview of the loans at their library.
·
Webservices are used for sending messages between guest and home library.
·
To be able to use this functionality, both the home and the guest library must have a working and installed webservices architecture.
·
[Dutch context only] To reduce the number of IP addresses that need to be accessed, each individual system will connect to a centrally hosted server, which will then connect to each individual library. Via this architecture, webservices access configuration only needs to take a single IP address check into account.
·
Information about ISIL codes, IP addresses and other settings will be handled via the same centrally hosted server. This server will provide a webservice that provides all the necessary information.
·
The guest loan mechanism is aimed at usage within a single country.
Please see the help of AFO 481 – Miscellaneous – Physical guest loans for a description of the associated parameters.
447.2 Enrolment at the guest library
This section describes the steps involved in registering borrowers.
447.2.1 Workflow
If a borrower wants to enroll at a guest library (AFO 431), the workflow will be as follows. The assumption is that the borrower indicates to the library (the staff member) that he is a borrower at another library [home library] and that he wants to register as a guest member [at the guest library].
1.
The system will check a general parameter (at the meta institution for circulation level) that indicates that Physical Guest Loans are supported [at the “client” side]. If true, then the screen to enroll a borrower has an additional control: a checkbox “Guest member”.
2.
If the “Guest member” checkbox is checked, the system will try to detect the home library's ISIL code [4 characters]. If that is not possible, the ISIL code can be entered manually in a text box. The system will also show a dropdown box containing all the available libraries. These two controls are preceded by a message “The system could not extract a valid ISIL code from the borrower barcode”. [The system will have a parameter that contains the test to be performed on the ISIL code field.] – If the member is a guest member, the system will not apply the locally defined borrower barcode format checks: any format will be accepted, as long as the barcode consists of at least 1 letter or number.
3.
The system show a message “The guest's home library is:” + home library details + “Please confirm that this is correct”. The form contains OK and CANCEL buttons.
4.
The system connects to the home library's system and checks if the borrower barcode is defined. If not, the home library will return an error message. If the borrower is known in the home library's system, the home system will have to check if [a] it support server-side physical guest loans, [b] the borrower has a borrower category that allows physical guest loans, and [c] the borrower record is not blocked. The home library will have a parameter that says which types of blocks are taken into account to determine whether or not the borrower is blocked for server-side physical guest loans: this may be (1) manual blocks and/or (2) one or more types of automatic blocks. If the borrower is, for one of the three reasons mentioned, not available for physical guest loans, the system will display an error message. Please note that the above parameter with regard to blocking can be defined for both (1) enrolment and, as a separate set of parameters, (2) the actual loans.
5.
If the above process is successful, the home library will send a subset of the data in the borrower record to the guest library. The data is displayed in the regular borrower entry form and the staff member can compare it to the information on the borrower's library card and/or his identity credentials. If the comparison is acknowledged by staff, the enrolment continues as any standard enrolment.
447.2.2 Specific features at the guest library side
The guest member can be enrolled with any available valid borrower category (these are the borrower categories that are available at the guest library). It may be that the guest library uses its standard set of borrower categories for this purpose, or that it uses one or more borrower categories specifically for guest members. This is at the guest library's discretion.
There is a parameter in AFO 481 – Miscelleneous that determines which borrower categories are valid.
There will be no mapping between the borrower category at the home location and the borrower category at the guest location.
The guest member's record will contain information from the home library. This information is inherited from the home library and cannot be modified at the guest library. Name and address fields are all inherited from the home library. These data fields cannot be modified by the guest library.
The guest member record can be clearly identified. The group Guest loans on the borrower overview screen contains the following lines:
-
guest library enrolment date
-
ISIL code of home library
-
last block status check at home library
-
last data check/updte from home library
-
name of home linrary
The borrower's enrolment, renewal and due dates are all inherited from the home library. These dates cannot be modified by the guest library. In principle, all other fields may be modified. In particular, fields such as “Can be approached for marketing purposes?” can be modified. Further restrictions on the fields that may or may not be modified will be identified at implementation time. It has to be possible to recognize both the enrolment date at the home library and the enrolment date at the guest library. Due date is always inherited from the home library.
The borrower does not need to pay a membership fee, as this is inherent to the concept of Physical Guest Loans. However, it is at the guest library's discretion to charge an enrolment/admin fee to the borrower. à The library can set this standard parameter, based on a specific borrower borrower category reserved for guest loans.
The guest library can register its own “blocks” (e.g. manual blocks) against the borrower record. Blocks that appear at the guest library are NOT sent to the home library. Of course the library can resolve this in another way (by contacting the home library by phone, email etc.).
If the data exchange from home library to guest library contains data fields that are not supported in the guest library, the data is discarded (e.g. the home library uses a phone number field which is not used by the guest library: in such a case the data is not mapped to another field, but discarded).
Mapping between field structures may be necessary. Examples: first and last name in a single field or in multiple fields; street number may be in a separate field, etc.
A guest member will not be included in any of the processes (at the guest library) that are related to membership renewal, such as: acceptgiro's, automatic invoicing, etc. All financial handling related to memberships are processed at the home library's side.
There will be no technical limitations (in the ILS) that will stop the guest library from approaching the guest member for marketing purposes. However, there should be / could be gentlemen's agreements between the libraries that they will not actively approach each other's members for membership purposes / membership switches. In other words: this should be taken care of outside of the ILS.
Each individual library can decide whether the storage of a loan history is allowed. (In other words: the guest library does not inherit this setting from the home library.)
If the member is deleted (at the guest library), the system will send an update to the home library, allowing the home library to update his information about the guest libraries for the specific borrower.
447.2.3 Specific features at the home library side
At the moment a borrower is registered as guest at the guest library, the guest library will send a message to the home library. This message enables the home library to register in which guest library (libraries) the borrower is enrolled. The home library also registers the date at which the borrower enrolled at the guest library.
On the borrower overview screen you can see at which guest library (libraries) the borrower is enrolled.
It is not possible to delete the borrower if he still has items on loan in a guest library.
After each modification to the identity or address fields, an update is sent to the guest library. The guest library will process the data and overwrite the locally stored fields. If the update contains data fields that are not supported in the guest library, the data is discarded (e.g. the home library uses a phone number field which is not used by the guest library: in such a case the data is not mapped to another field, but discarded).
The home library will have a specific flag (field) in the borrower record to block the borrower specifically for guest membership. This is done via the manual block option.
If the borrower is deleted at the home library, a message is sent to the guest library. This will allow the guest library to delete the borrower from the database, or mark his record as “to be deleted” in case the deletion is not possible (e.g. because he still has outstanding items). In the latter case it should not be possible anymore that the borrower loans items.
447.3 Loans at the guest library
This section describes the steps involved in the loan process at the guest library.
447.3.1 Workflow
If a guest member lends an item at the guest library, the workflow is somewhat different from “standard” loans:
·
If a guest member is identified, NO request is sent to the home library. The assumption is that it will be too “costly” from a performance point of view and functionally not relevant enough to check the data online. [If desired, the guest system may require an update on all guest borrowers from the home library during an overnight process.]
·
An item is lent to the guest member using the standard circulation Loans AFO (411). It is registered in the guest library's system as any “standard” loan. Please note that the loan is processed based on the guest library's parameter settings and that this processing is independent of any home parameter setting. This is, most prominently, visible in the handling of the maximum items on loan: this is handled based on the guest library's parameters and independent of the current number of items on loan at the home library. The latter also implies that a borrower who is a guest member at five different libraries will have a separate number of items on loan for each location; no attempt to aggregate / consolidate this data (these maximums) is made.
·
When the Loan session is finished, the system will send a message (via a webservice) to the home library. This logical message will in fact consist of two physical messages: [1] an “Insert item” message to insert the item that was lent; and [2] a “Loan item” message to inform the home library that the borrower has lent and item at the guest library. The home library will process these messages and store the information in its database. [See the introduction for an overview of the areas in which this data is displayed.]
·
All further processing (renewals, overdues, invoicing, etc.) is handled by the guest library. However, the home library's administration will be updated on a regular basis to reflect what is happening at the guest library.
447.3.2 Specific features at the home library and updates between guest and home library
If an item is renewed at the guest library, if an overdue is sent, if an invoice is sent, etc., - in all these cases the guest library will send an update to the home library. [To state the obvious: this is of course relevant only for items that were lent at the guest library.]
Items that were lent at a guest library are displayed in the items on loan list at the home library side, but they cannot be renewed.
Because of the fact that it is likely that the guest library's item category is not known at the home library's side, the system will allow the definition of an item category mapping. If this mapping is not defined, a default item category will be used.
The home library will store, in its circulation transaction file, a transaction for each message that is received from the guest library. These can be used for e.g. reports and statistics.
447.4 Returns at the guest library
This section describes the steps involved in the return process at the guest library.
447.4.1 Workflow
Items that were loaned at the guest library can be returned either at the guest library or at the home library. The latter type of returns is described in the next chapter. This chapter deals with returns at the guest library only. The returns may be either via a selfcheck station or via a staff workstation.
The workflow is as follows:
·
The item is returned at the guest library. This is a standard return (with fine calculation based on the guest library's parameters, etc.).
·
The guest library sends a message (via a webservice) to the home library. The home library removes the items from the borrower's list of items on loan.
474.4.2 Updating the home library's system[//]
When an item is returned in the guest library, the home library receives a (webservice) message that indicates that the item is returned.
The item will be removed from the borrower's list of items on loan.
The transaction is stored in the home library's transaction file, for later reporting and statistics.
447.5 Returns at the home library
This section describes the steps involved in the return process at the home library.
447.5.1 Workflow
Items that were loaned at the guest library can also be returned at the home library. The returns may be either via a selfcheck station or via a staff workstation. The workflow is as follows:
1.
The item is returned at the home library. The system will detect that the item was loaned at a guest library and ask for a confirmation (“Item loaned at guest library [Name of Library]. Do you want to proceed?”). [If the return is processed via a selfcheck station, this message will not be displayed, as it is unlikely that all selfcheck systems will support this functionality.]
2.
The home library sends a message (via a webservice) to the guest library. The guest library will calculate fines, etc. and register the return in its database. If there are fines, these are noted against the borrower record (at the guest library, NOT at the home library). A message may have to be sent from the ILS server to the selfcheck station to indicate that the item must be dropped in a separate sorting bin.
3.
The guest library sends a message to the home library indicating: whether or not the return was successfully processed + the fine amount [this is used purely for information purposes].
4.
If the loan was successfully processed, the home library's system will display the success status + the fine amount (if any) + a message that the item should be returned to the guest library.
5.
The home library removes the items from the borrower's list of items on loan.
447.5.2 Special considerations
Apart from the situation described in the previous paragraph, there are no other specific situations with regard to self-service stations. Returns on a selfcheck stations are handled in a similar way as the staff client returns.
Calculation of fines is done based on the rules of the location where the material is returned (“local rules apply”). This may result in the home library collecting a fine that should be due to the guest library. However, no attempt will be made to solve these issues, because the assumption is that these cases will be very rare. No reconciliation or clearing house function will be implemented.
Overdue notices and invoices are sent by the guest library (“local rules apply”).
The above rules may result in some specific situations. Consider the following:
·
The guest member loans item A at guest library A.
·
He does not return the item after multiple overdue notices, which results in an invoice being sent from library A.
·
The borrower then returns the item at home library B.
·
The fine calculation is done with the rules of library B.
·
The borrower pays the fine at library B.
·
The result of all this is that the invoice (book fee) at library A will still exist in library A's system.
The assumption is that such situations will occur only very, very rarely, - and therefore they will not be solved in the ILS. They need to be resolved pragmatically, with a procedure outside the library system.
447.6 Batch processes
AFO 447 is used to for the batch processes to update the guest loan information.
It is recommended to run these processes daily (preferably as part of the scheduled overnight processes).
After starting this AFO a menu screen will be displayed:
The options are described below.
447.6.1 Update borrowers
The update of borrower information must be started by the guest library and requests for each borrower an update from the home library. This includes:
· update of details in the borrower record such as address
· update of the borrower's block status
· update of the borrower barcode
After selecting this option the standard screen for scheduling processes will be displayed.
447.6.2 Update items
The update of item information must be started by the home library and requests for each loan transaction processed at the guest library an update from the guest library. This includes:
· update of the loan period